Device/viewport visibility ("Hide on…") is not honored on the field wrapper
at render time — the field render pipeline bypasses core's render_block
visibility filter — so the control did nothing. Disable the 'visibility'
block support on field and input blocks on both the JS (shared/settings,
input) and PHP (register_block_type_args filter) registrations so the
non-functional option no longer appears. Labels keep visibility support.

See FORMS-694.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…y control

…ports array

The standard jetpack/input was disabled, but the field-specific input blocks
(input-range/slider, input-rating, input-image-option, phone-input, dropzone/file)
define their own supports and don't share defaultSettings, so the control still
showed on them. Add visibility:false to each (JS) and broaden the PHP filter to
match all jetpack/input* plus phone-input and dropzone. Verified in-editor: every
field-* and input block now hides the control; only label keeps it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Per team decision, the choice/option blocks (option, options, fieldset-image-options,
and the deprecated field-option-radio/checkbox) are inputs in effect — they flatten
through the same field-shortcode path, so visibility is inert on them. Add
visibility:false (JS) and extend the PHP filter (drop the field-option-* exclusion;
add the option containers). Label is now the only forms block keeping the control.

Verified in-editor: every field/input/option block hides the control; only label shows it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…gend a11y

Addresses review on #49973 (FORMS-694).

- Fields: add a render_block filter (drop_field_hidden_everywhere) that drops a
  field whose metadata.blockVisibility === false before Contact_Form::parse()
  sees it. Disabling the visibility *support* stopped core's release-WP filter
  from honoring saved full-hide (the reorder fix, gutenberg#78780, is
  unreleased), so previously-hidden fields would reappear. Doing the drop
  ourselves is version-independent and required-safe: the field is fully removed
  from the form, so its required check never runs.
- Grouped fields: when the legend label is fully hidden, move the label onto the
  <fieldset> as an aria-label so radio/checkbox-multiple/image-select/rating keep
  an accessible name, mirroring the single-input fallback.
- Fix the label's support key (blockVisibility -> visibility; the old key was a
  no-op) and update the registration test.
- Tests: unit + do_blocks integration coverage for the field drop; render-level
  coverage for the legend aria-label across both fieldset code paths.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ding

Optional follow-up to the legend a11y fix (FORMS-694). The visibility control
now survives only on the label block, so per-viewport hiding hides the
<label>/<legend> (display:none on that viewport) while the input stays visible —
leaving the field with no accessible name on that viewport.

Route every aria-label fallback site (input, phone, textarea, select, grouped
legend) through a single predicate that treats the label as hidden on either
full-hide (labelhiddenbyblockvisibility) or per-viewport (a wp-block-hidden-*
class on the label), and prefer the label text as the fallback name so it
matches the visible label where the per-viewport label still shows (falling back
to the placeholder only when there is no label). The render_label /
render_legend_as_label early-returns stay full-hide-only, so per-viewport keeps
the label rendered rather than removing it.

This is intentionally a standalone commit: if we'd rather keep the PR minimal and
treat per-viewport label hiding as visual-only for now, it can be dropped without
touching the rest of the fix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…S key, changelog

Follow-up to the review on #49973 (FORMS-694):

- Slider: the bare <input type="range"> was the one single input missing the
  hidden-label aria-label fallback; add it.
- Lift the input aria-label logic into a shared get_hidden_label_aria_label_attr()
  helper used by every path (input, phone, textarea, select, slider, legend) so
  none get skipped again. The fallback now takes the raw placeholder (not the
  pre-built placeholder='…' fragment), so an empty-label field no longer renders
  aria-label="placeholder='…'", and the attribute is omitted entirely when there
  is no label and no placeholder (no empty aria-label).
- label/index.js: match the PHP fix — blockVisibility -> visibility support key.
- Changelog: drop the redundant "Forms:" prefix.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…its label is hidden

Follow-up to the review on #49973 (FORMS-694). The file field's dropzone
<div role="button"> is the interactive control, but its accessible name is
otherwise the generic "Select a file to upload.", so two upload fields whose
labels are hidden are announced identically.

Prefix the field name onto the dropzone's aria-label when the label is hidden
(full or per-viewport), reusing the shared block-visibility name resolver — the
same fallback the other single inputs got. Extracted into
get_file_dropzone_aria_label() so it's unit-testable (the full file render
short-circuits without an active Jetpack).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

… paths

- ReflectionMethod::setAccessible() is deprecated on PHP 8.5 (a no-op since
  8.1), and the forms suite fails the build on deprecations, so the file
  dropzone test broke CI on 8.5. Guard the call with PHP_VERSION_ID < 80100,
  matching the existing pattern in Contact_Form_Block_Test.
- Add render tests exercising the hidden-label aria-label fallback through the
  textarea, select and country-selector phone paths (the remaining changed
  lines that weren't covered), which also verifies the fix across those types.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>